1. Field of the Invention
The present invention relates generally to a distributed database, and more particularly, to a system and method for integrating multiple transaction processing systems and maintaining consistency of codes used therein.
2. Related Art
Businesses perform a variety of time consuming administrative functions. These generally include order processing, inventory control, accounting, manufacturing control, and personnel recordkeeping. Such functions can become quite arduous for large companies. As technology has evolved, computerized database management systems have become available to automate these processes. Such database management systems are also known as "transaction processing systems".
A database management system is a set of software programs that controls the organization, storage and retrieval of data (also called codes) in a database. The database management system handles the repetitive tasks involved with data processing so that a user is free to perform higher level functions.
A database stores data as a collection of related files. Each file contains a collection of related logical records, and each logical record contains a collection of related fields. A logical record may be made up of multiple physical records. That is, a field of a logical record may either be a value or another record. In the latter circumstance, the record having such a field is said to be a base record, and the record which constitutes the field is a support record of the base record.
Because a database management system uses a number of rules to process the data which it manages, the database management system also controls the security and integrity of the dam. When data corruption or ambiguity occurs, it most often results from operator (human) error. Such ambiguity is particularly prevalent between multiple transaction processing systems. This is explained in detail below.
As computer technology has advanced in the last twenty years, businesses have generally automated their administrative functions in a piecemeal fashion. For example, a transaction processing system would be purchased to automate an accounting department. Next, a transaction processing system would be purchased to automate inventory control. Finally, a transaction processing system would be installed to handle order processing. This type of bottom-up (rather than top-down) computerization often resulted in a number of independent systems which are unable to effectively communicate or share data.
Accordingly, any communication between the different transaction systems requires operator intervention. For example, if a new product is added into the order entry system, it must also be manually entered into the accounting system, otherwise a bill could not be prepared on the accounting system. Many problems result from this lack of communication/data sharing between the various transaction processing systems.
First, the integrity of data between the different transaction processing systems cannot be ensured. For example, if a product code PC101 is used to represent product X in the order processing system and a product code P101 is used to represent the same product in the inventory control system, then attempts to share data between the two systems will cause errors. It is not clear whether PC 101 and P 101 represent the same or different products. Similarly, it is difficult to determine whether a customer entered into the accounting system as John Doe and into the order entry system as J. Doe Company are the same or distinct entities.
A second deficiency of the conventional transaction processing environment is the lack of data currency. Conventional systems do not communicate with one another in an on-line manner (i.e., in real time). Rather, they are periodically (e.g., nightly) reconciled with one another. Consequently, the different systems in the transaction processing environment may simultaneously store different values for data that they supposedly share. For example, suppose records on both an inventory system and an order processing system indicated that 3000 units of a particular product are available. A transfer of 2500 of the units to a company subsidiary is then entered on the inventory system. The inventory system would then indicate that 500 units were available. However, until the next reconciliation between the systems, the order processing system would continue to indicate an availability of 3000 units. This could mislead a user of the order processing system to believe that 3000 units of the product remain in stock.
The lack of data integrity and data currency can result in a number of business problems. For example, it is possible for a user to promise delivery of a product which is not in stock, to deliver a product to a customer with a delinquent payment history, to ship an incorrect product, to bill an incorrect location, etcetera. Each of these errors are highly undesirable. However, they frequently occur in conventional transaction processing environments.
A third deficiency of the conventional transaction processing environment is the lack of standard user interfaces. That is, a user of an accounting system may not be able to use the order entry or inventory systems. If a person is required to use multiple transaction processing systems, then he or she must learn the user interface of each. This increases the training requirements for system users.
Similarly, the conventional transaction processing environment lacks standard application interfaces. That is, each transaction processing system must have a distinct interface to every other transaction processing system from which it receives data. Moreover, the lack of standard interfaces impedes maintainability of the transaction processing systems, as modifying the physical structure of a record in one transaction processing system necessitates modifying the application interface of every other transaction processing system which accesses that record.
A fourth deficiency of the conventional transaction processing environment is that the structure of the environment limits the number of data views. Specifically, the environment cannot present a view which combines data from records on distinct transaction processing systems. For example, if the inventory system maintained records on production cost only on a per product basis and the accounting system maintained records on revenues only on a per product basis, the conventional transaction processing environment could not consult both systems to present a view of profits per product.
What is needed is a maintainable transaction processing system which ensures the integrity and currency of data; which has consistent user and application interfaces; and which can present multiple data views.